產品團隊：「根據轉化漏斗，我們發現在第 3 步後，流量減少。我們想要知道為什麼使用者不繼續使用，本週的目標是『我們怎麼找出原因？』」

開發者：「我們必須找出一種方法與這些使用者聯繫、或許我們可以...」

CTO：「我不明白你們的產品策略是什麼？」

產品團隊：「我們正在嘗試診斷問題、以便決定要建構甚麼，我們有這個目標，希望藉此發掘周邊的問題。」

CTO：「不，你需要有一個策略。在一週之後，我想看到一個規格文件、包含網站內容，所需的後端及接下來 3 個月要建構的所有東西。」

如果產品團隊不確定「為什麼」要做（建構）一個功能，他們怎麼可能告訴你要建構什麼？在知道要解決什麼問題後，他們才能據此發想、設計出對的產品、要建構的功能。

那此時 CTO 談的「策略」究竟是什麼東西呢？
CTO 其實想要的是一個計畫，而非一個策略。

好的策略不會是一個詳盡的計畫，好的策略是一個幫助我們做決定的框架。

人們經常認為產品策略就是...利害關係人對功能的『願望清單』。
或是如何實現這些願望的文件和詳細資訊，或許文件當中還充斥著「創新」、「平台」之類炫砲的流行語。

CTO 想溝通的是產品的最終狀態，本質是正確的。我們必須朝願景努力！但是，在未經驗證前，花大量心力在這些尚未驗證的「願景+玄虛」的功能、產品組合，將會非常危險！

那究竟策略又是什麼呢？
當別人問我，我的策略是什麼時，多數人開始複誦他們的待辦清單。

接著如果又問，如何確保正在做（建構）正確的東西，多數人也很容易回答：「我不知道、我主管（or 老闆）告訴我應該要做這個、應該要有這個功能」

如果一層一層網上問，或許答案也可能有趣的令人害怕，「來自研究指出」、「必須與競品有相同功能」，最可怕的是...，CEO：「顧問公司建議我們做這個」

這些回答都沒有與願景、策略產生連結，或是呼應，這也是我們常落入建構陷阱的原因。

字典中的策略：「一個旨在實現主要、總體目標的行動方針或是政策」。

當企業花費數月來製作「策略性計畫」時，創造了將完成、全面且詳細的任務清單、費用及預算還有預期效益等等，即是將策略視為計畫，這將使我們落入建構陷阱。因為每當新增一個功能時，我們沒方法去評估、衡量該功能是不是一個對的功能。

在《不服從的領導學（The Art of Action）》一書中，寫道：

策略是一個可展開的決策框架。使行動能實現預期成果，受當前能力的限制，與現存環境相一致。

一個好策略能超越功能的迭代，更聚焦在高層次的目標、願景
一個好策略能支持組織、企業數年 － 如果每年、每月都在更改策略又沒足夠充分的理由（如數據佐證、市場）的話，那策略是計畫而不是框架
參考文章
跳脫建構陷阱 產品管理如何有效創造價值